Event logging and performance analysis system for applications

ABSTRACT

An event logging and analysis mechanism which creates an event object for event of an application to be logged. The event logging mechanism logs into the event object the start time, end time and other information regarding the event. The analysis of the collected event objects may include hierarchical and contextual grouping as well as aggregation of events considered to be identical. The mechanism operates independent of the application whose events it logs and can be turned on and off independently. A user may define the levels of hierarchy and contexts upon which to analyze the event objects.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to software applications. Morespecifically, the present invention relates to the performance analysisand logging of events generated in applications.

2. Description of Related Art

One operation in fine-tuning and troubleshooting of information systems,such as a computer application, is to measure the “performance” (timetaken) to deliver a requested result from that system. Performance toolshave been developed which measure certain events from an operatingsystem perspective by measuring the time taken to process operationssuch as computations and I/O (Input/Output). Performance can also bemeasured within an application itself. For instance, a videoconferencingapplication may have a mechanism for collecting and presenting metricsregarding the number of frames per second displayed on the screen or thenumber of frames skipped (not displayed). Such performance analysismechanisms are typically built into the executable code of theapplication. Thus, typically, applications that do not have performancemeasurement code already built-in, must either completely forgo muchmeasurement or rely on a third-party measurement tool. Due to thepeculiarities between the way in which different software applicationsexecute, generic measurement tools lack usefulness. If not specificallyprepared for the application much of the information is geared towardsampling at given intervals what the application is doing. This does notnecessarily give information that the user may be looking for or isinterested in. Typically, the user must wade through piles of useless oruninteresting data regarding performance and may thus be unable to pickout those metrics of greatest importance.

All performance tools must preferably be operating as close, in a systemor network sense, to the measured entity to eliminate the addedmeasurement noise of latency which may skew results. The latency indelivering data over a network between clients and server completelyrenders useless the measurement of the operations themselves. In aclient-server environment, there is often no separable measurement ofclient from server and server from client in regard to operations. Forinstance, in database applications where a server is being accessed andqueried or updated by a client, timing of server operations needs to beisolated from the latency of network transfer. Likewise, timing ofclient operations may also need to be isolated from the very samelatency.

What is often measured is only the time to gather the data from theserver, and often, this is performed on the server side. Often, whenpreferred on the client side, this puts additional processing load onthe client which can in turn degrade the accuracy of the measurement.When such measurements deal only with data collection time (request andresponse) rather than also the display of results, they are burdensometo the client and from the standpoint of the user, irrelevant.

There is a need for a performance measurement tool that can workinteroperably with third-party applications, which is application andplatform independent, and can be quickly and easily initiated whennecessary and shut down when not. There is also a need for a performanceanalysis system that allows measurement of selective operations of anapplication.

SUMMARY OF THE INVENTION

An event logging and analysis mechanism is provided which creates anevent object for event of an application to be logged. The event loggingmechanism logs into the event object the start time, end time and otherinformation regarding the event. The analysis of the collected eventobjects may include hierarchical and contextual grouping as well asaggregation of events considered to be identical. The mechanism operatesindependent of the application whose events it logs and can be turned onand off independently. Further, in some embodiments, a user may definethe levels of hierarchy and contexts upon which to analyze the eventobjects.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart describing basic event logging as utilized in oneor more embodiments of the invention.

FIG. 2 is a flowchart outlining hierarchical event grouping, aggregationand statistics computation according to one or more embodiments of theinvention.

FIG. 3 is an operational system diagram of event logging and displayaccording to one or more embodiments of the invention.

FIG. 4 is an organizational tree diagram of grouping, subgrouping andgranularity according to one or more embodiments of the invention.

FIG. 5 illustrates an example of recursion as applied to event loggingand analysis according to one or more embodiments of the invention.

FIG. 6 is a computer system diagram that utilizes and implements one ormore embodiments of the invention.

DETAILED DESCRIPTION

FIG. 1 is a flowchart describing basic event logging as utilized in oneor more embodiments of the invention.

In accordance with the invention, event logging is characterized by itsability to be turned on or off at any instant in time during anapplications' run-time. One advantage of the invention is that eventlogging requires no special linking to libraries or recompiling and neednot be present as a feature in the design and compilation of theapplication whose events are to be logged. The performance of theapplication being measured is not impaired nor does its behavior changebecause the event logging is transparent from the application'sviewpoint. One feature of the event logging mechanism is the ability todefine the granularity at which “events” of an application are measuredand displayed. The event logging mechanism of the invention alsoperforms aggregation and grouping of event statistics such that ahierarchical view as well as contextual information is presentable tothe user.

The event logging mechanism (referred to as the “event logging center”)is built within a foundational layer that is common to a class ofapplications. Such a common foundational layer is sometimes referred toas a “framework.” The framework is a common platform upon whichapplications may be built such that they take advantage of linkablelibraries of code and standard routines that can be utilized during arun-time or at application development. Examples of a framework are theJava virtual machine and WebObjects (a product of Apple ComputerCorporation). In addition to developmental frameworks, foundationallayers may also be as low as the operating system itself. In this way,any application capable of running within that operating system can makeuse of operating system calls that perform event logging. Thus, thefollowing description will refer variously to “operatingsystem/framework” to indicate the lowest level of abstraction, common toall applications, that embeds the event logging center and itsfunctionality. Further, the words “operation” and “event” will be usedinterchangeably to mean a piece of code that executes to perform somefunction during the flow of an application's run-time.

To achieve event logging, for each event or family of events identified,first the operating system/framework must check to see if event loggingis turned on (block 110) in relation to an operation to be performed. Toavoid any penalty to the execution of the operation that may besubjected to measure, the test of whether event logging is on or off forthe operation should be a Boolean test. One mechanism for implementingsuch a Boolean test is by setting/resetting a flag whose state can bechecked. There are flags created for each and every event or family(“group”) of events that the application or operating system/frameworkidentifies during run-time. If event logging is not on, then theoperation is performed without any logging or measuring (block 100).

If event logging is turned on, then an “event object” is created (block120). The event object is a software object or memory space designatedfor the log information be stored and later, accessed for analysis.According to one embodiment of invention, the event object subsists in amemory space called an “event center” wholly independent of any otherapplications, including the application whose operations are beinglogged. The event object is created by the framework. The event objectmarks the time index (obtainable, for instance, by returning the systemclock's time information) at the start of the event (operation) beinglogged (block 130). The marking of the time index may be as simple as aread of the system clock and subsequent store in the event object. Theoperation being timed is then performed as it normally would were eventlogging not present (block 140). The operation itself returns noinformation other than whatever software mechanism is used to indicateits end (e.g. return of a function's result). When the operation iscompleted, the time index at the event's end is marked in identicalmanner with that of event start demarcation (block 150). In addition tostart and end times, event objects may encapsulate information regardingwhat the operation actually did from a functional standpoint.

While the application is running and while event logging is still on, nospecific analysis of the data present in the event object is performed.The process of marking start and end time indices according to FIG. 1can be repeated for any objects at any level or context as are desired.Each operation (event) whether at a high grouping level (such as theentirety of a sub-routine) or at a lower level (such as a specificcomputation of a function as one of many within a sub-routine) can beassigned its own event object which marks its start and end time index.A new event object is instantiated for every occurrence of an operation,if the operation is repeated. Further, a user can select points ofinterest prior to invoking event logging to measure only certainspecific events as opposed to a brute force logging and measurement ofall events. This can serve to reduce the amount of memory/storage spaceutilized by the logging process and allows results displayed to the userat a later stage to be filtered of non-pertinent or non-critical eventstatistics. Further, as demonstrated below, event object based loggingaids in developing a hierarchy of event statistics, grouping of eventsand contextual differentiation. The structural and procedural nature ofmost code can be exposed in this manner and statistics can be used tomonitor the execution efficiency program flow, rather than just measuresof input/output timing.

The following description refers to “events” but should be understood tomean “event objects” which result from the logging of actual events thathave occurred in an application. Once event logging is turned off, only“event objects” remain to represent the actual events which occurredwith the application, and thus, “event objects” and “events” are viewedas one in the same.

FIG. 2 is a flowchart outlining hierarchical event grouping, aggregationand statistics computation according to one or more embodiments of theinvention.

The invention in various embodiments presents two inter-relatedfeatures, namely, hierarchical event grouping, aggregation andcontextual event grouping. “Hierarchical event grouping” refers to adifferentiation by structural or procedural level within theapplication's execution of events that take place. “Aggregation” refersto the collecting of identical events (events that are repeated) intoone event via averaging and other such means. “Contextual eventgrouping” refers to the grouping/aggregating of similar eventsconsidered identical by virtue of their context. Each of these featuresmay be pre-configured into the event logging or customized by the userat the time event logging is invoked or as in FIG. 2 may be configuredor reconfigured when event statistics are viewed which may be afterevent logging has been turned off.

In FIG. 2, a user selects the granularity (noted by a variable “grain”in FIG. 2) referring to the lowest structural level of an application'scode or event space that is to be aggregated (block 210). Further, theuser can select/define contexts whose events are to be considered asidentical for purpose of gathering the statistics. After an event log iscompleted for a given run-time instance (i.e. when events between thestart and finish of an event logging session have been logged), then allof the events are grouped or arranged according to their functionallevel within the code of the application or according to user selectedgrouping (block 220). The grouping of events is enabled by theoperational information provided by the application during eventlogging. The grouping of events in a hierarchical sense can takeadvantage of the “call stack”, which is a operating system ordering ofexecutable instructions resulting from the execution of applicationcode. The call stack, advantageously, is by nature already organized inrough order of program flow. A developmental framework may also containsuch clues as to the possible grouping of events. Such hints and callstacks allow the event logging center to determine a default groupingthat may serve as a starting point or substitute for user customization.

The grouping of events, once completed, puts all events into astructural framework that starts from a coarse “granularity” to a finerand finer level of granularity and by nature, may be recursive/loopdriven. Each group of events, at every level of granularity, will bereferred to for the sake of simplicity as a “subgroup” to indicate thatthat it is potentially a logical subset of yet another group of events.Accordingly, once events are grouped from the event center a loop ensues(from block 230) that runs through each subgroup of event objects andrecursively proceeds to a finer grain subgroup until the desired levelof granularity is reached. As long as the subgroup level being processedis less than the variable “grain” (granularity level) (checked at block240), a first set of processes shown in blocks 250 through 270 areperformed.

Within each subgroup, the events therein are further divided into afiner and finer granular level of subgrouping (block 250). Within thecurrently processed subgroup (from which further subgroups wereextracted in block 250), the statistics for that subgroup are computed(block 260). These statistics on the level of the subgroup are thendisplayed (block 290) (see description below). The display of statisticsaccording to block 290 does not break out of the loop ensued at block240, but is performed in parallel with it. Recursively, for each furtherdivided subgroup (as divided in block 250) flow returns to block 230which traverses through the events of the newly created subgroups. Thisprocess is recursive and blocks 250 through 270 are repeated andrecursively so, until the (sub)group level is less than the granularity(represented by “grain”) (checked at block 240). This indicates that thedesired lowest level of grouping has been achieved and that thehierarchy of event grouping is completed. The event log would at thispoint have been traversed completely and event objects thereinhierarchically organized (for example, see FIG. 4 and descriptionbelow).

As such, all of the events that belong to a particular subgroup areaggregated and this aggregation is performed for each subgroup that hasbeen defined by the recursion into the event log. Each “aggregate” is acollection of events that are identical and considered to be singleevent. Statistics for each aggregate may be computed (block 285) bycomputing the duration for each individual event and combining themthrough averaging and by maintaining any other desired statistics suchas modal or deviation information. These statistics are then displayedto the user (block 290). The display of statistics (block 290) may bearranged in a hierarchical manner as well, showing the user the groupingof events and structural flow of the application. Advantageously,subgroup level statistics are computed during the recursive groupingprocess and thus do not have to be recomputed (block 260).

FIG. 3 is an operational system diagram of event logging and displayaccording to one or more embodiments of the invention.

FIG. 3 shows an exemplary database application 320 where queries andupdates (transactions) are performed by a user upon a database 350.Application 320 executes or is built on top of a operatingsystem/framework space 300 and connects to the database 350 to performtransactions thereon. According to the invention, an event loggingcenter 310 is provided as part of the operating system/framework 300.Event logging center 310 occupies a space in memory and executes underthe operating system/framework 300 but is separate and independent ofapplication 320. Other layer of abstraction. The event logging center310, may be turned on and off by one of several means. The application320 may have a provision for turning on event logging. If not, eventlogging may be turned on and off by a local web browser which alsosubsists in operating system/framework 300 or a remote web browser 340which may not be part of the operating system/framework 300 at all, butmerely sends and receives data with applications within it. There may beother means of turning on and off event logging such as starting eventlogging from within the auspices of the event logging center 310.

Once invoked, event logging proceeds for each event by the application320 initiating a call to create an “event object” 315 in the eventlogging center 310 which is a reference to the event's start time, endtime, and operational information (what the event does). For each event,a process similar to that shown with respect to FIG. 1 above isperformed. The event object 315 subsists in the event logging center 310which handles its memory allocation and storage. Once the event object315 is created for a given event, the application 320 sends its starttime to the event logging center 310. The event logging center 310 thenrecords this start time into event object 315. When the event iscomplete, application 320 sends its ending time index to the eventlogging center 310. This process repeats over and over again for eachevent that is to be logged and continues until event logging is turnedoff. For each event subgroup, a Boolean flag is assigned and checked,which is independent of other flags for other events. Application 320may inform the event logging center 310 of special events or subgroupsin addition to default clues provided by call stacks and othermechanisms that are within operating system/framework 300.

When event logging is turned off, the event logging center 310 performshierarchical event grouping, aggregation and contextual grouping, asdescribed above with respect to FIG. 2. Any event objects that areincomplete (do not have ending time information) at the termination ofevent logging are destroyed and not counted. When statistics arecomputed at each aggregate or subgroup, they are displayed to the user.These results may be displayed on a graphical user interface such asthat provided by local web browser 330 or remote web browser 340. Thedisplay of results may be in a drill-down or “threaded” fashion so thatgroupings and subgroupings can be easily visualized. As well, thedisplay can show event details individually.

In one embodiment of the invention, both the local web browser 330 andremote web browser 340 have identical displays of event statistics andcannot configure their own displays based upon the raw statistics of theevent logging. In yet another embodiment, each of the local web browser330 and remote web browser 340 may specify the grouping of events thatthey desire communicating this to the event logging center 310. In thisway, each user may alert the event logging center to their ownpreferences and see statistics in different contextual or hierarchicallygranular groupings on their respective displays. The configuration ofevent grouping and contexts may occur prior, during or after eventlogging. Control and display of results via a web browser in oneembodiment is advantageous in that the event logging can be crossplatform.

As an example, consider a database query for a customer list ofcustomers who have outstanding orders. Several levels of subgroupingcould be defined. For instance, the operation can be contextuallyconsidered from the start of the query to the display of the data fromthe database. Within the display, a list of customers involvesindividual fetches (one for each customer) form database 350. Each ofthese fetches may be considered an “event” whose timing is recorded inevent objects such as event object 315. They are grouped under thecoarser level subgroup of the total database fetch. The coarsest levelunder the query event subgroup consists of the subgroups: queryprocessing, database fetch and then display of results. Each of thesesubgroups (such as the individual fetches within the database fetch maingroup) may have further subgroupings and so on.

FIG. 4 is an organizational tree diagram of subgrouping and granularityaccording to one or more embodiments of the invention.

The diagram of FIG. 4 represents an exemplary event hierarchy of anapplication. At the coarsest level 410 of granularity, is theapplication itself. The application as a whole is considered an eventthat has its own start and end. For example, if the application is a webbrowser, then the web browser, once started may generate a number ofpages. The generation of each page is also an event and the group of allpage generation events are thus considered a “subgroup” of theapplication event. This subgroup of page generation events are shown assubgroup level 420, which is finer in granularity than level 410 butcoarser than its children. Note that there is no particular chronologyof events represented in FIG. 4, but rather, a hierarchicalorganization.

Subgroup level 420 three page events, page 1, page 2 and page 3. Thesepages may be simultaneously generated (on simultaneous executionthreads) or generated one after another, but in any case, arehierarchically related in the same manner as that shown. The nextsubgroup level 430 shows a number of component events—component A,component B, component C, component D, component E and component F—whichbelong variously as children of the page events belonging to subgrouplevel 420. The event logging mechanism does not necessarily followassumptions about events since different instance of events within thesame subgroup may have a different behavior. Page 1 of subgroup level420 has only member belonging to subgroup level 430, namely, componentA, while page 2 has three members in subgroup level 430—components B, Cand D—and page 3 has two members in subgroup level 430—components E andF. Subgroup level 440 has children of components in level 430 which areof an even finer granularity. Component F of subgroup level 430 has nochildren below it, and thus no members belonging to subgroup level 440.The vent logging center is notified of this behavior during the loggedapplication's runtime and can adjust its analysis of the logaccordingly. This allows the event logging center to dynamically arriveat the hierarchical grouping of the events logged, rather than justguessing. The process of subgrouping extends until the finestgranularity of subgrouping is reached. As described above, the user ofthe event logging may specify how granular the event statistics and logshould be. In the example shown in FIG. 4 the user desired only fivelevels of subgrouping down to level 450. The finest granularitysubgrouping level 450 is a subgroup of level 440 which is a subgroup oflevel 430 and so on.

As depicted in FIG. 4, some subgroup members have one child, multiplechildren or no children at all. The hierarchy is maintained regardlessof whether only one child or multiple children persist for a givenmember of a subgroup. The event logging statistics can be arranged in asimilar fashion to that shown in FIG. 4 but in a drill down fashion. Forinstance, clicking on the statistics for the page 2 event would yieldstatistics for component B, component C and component D and so on. WhileFIG. 4 primarily depicts a hierarchical grouping, it could also beviewed of as a contextual grouping. For instance, each of the pages,page 1, page 2 and page 3, could be different types of pages generated.One could be an information page, the other a form page for inputtingand so on. Each of these page events could be considered to be indifferent contexts and thus, forgo/supplement the aggregation ofstatistics that might normally occur given merely the hierarchy. Thisadded level of differentiation may be user or application specified andcan provide a different statistical view of the events of theapplication.

FIG. 5 illustrates an example of recursion as applied to event loggingand analysis according to one or more embodiments of the invention.

FIG. 5 shows an exemplary mapping of events in a database queryapplication. A root event or subgroup 510 at the coarsest level is onethat for example is the initialize or start-up of the applicationitself. Event 510 is a “root” event since it has no “parent” event (i.e.prior to event 510, other application events could not commence). Thegraph of FIG. 5 shows events occurring sequentially down the width ofthe page, and “child” or nested events to the right of their respectiveparent. After root event 510 ends, event generate page 520 commences.

Event generate page 520 cannot end until its subgroup of events alsoend. However, this is a necessary but not sufficient condition, sincethe end of the subgroups under event 520 does not necessarily mark theend of event 520. For instance, for event generate page 520 to end,first, initialize page event 530 must be started (indicated by the arrowfrom event 520 to event 530) and end (indicated by the curved arrowproceeding back from event 530 to event 520). As indicated by FIG. 5event generate component 540 occurs chronologically following the end ofevent 530. Generate component 540 is not complete until it's nested orchild event, the event “database fetch to initialize component” 550 iscomplete. Events 530 and 540 are at the same level of granularity. Event550 is at a finest level of granularity since it has no children of itsown. Generate component 540 is complete once event 550 returns itsresult, and this will trigger completion of the event subgroup of event520 composed of event initialize page 530 and event generate component540.

After generate page 520 is complete (and thus, all subgroup and nestedevents 530, 540 and 550), then event flow proceeds chronologically to“get request” 560. When get request 560 is complete another event“generate reply for request” 570 is performed.

Event logging for the events of FIG. 5 could be displayed and would belogged hierarchically in this manner:

start  510 (A) perform 510 end  510 (B) start  520 (C)  start  530 (D) perform 530  end  530 (E)  start  540 (F)   start  550 (G)  perform 550   end  550 (H)  end  540 (I) end  520 (J) start  560 (K)perform 560 end  560 (L) start  570 (M) perform 570 end  570 (N)

In the above exemplary event log for the events of FIG. 5 the numbersrefer to the event numbers therein and the letters in parenthesis aretime indexes for each start and end. The duration of event such as event510 would be computed as “B-A” for example. The duration of event 520could be computed as “J-C” rather than computing it as the sum ofdurations of all nested or recursed subgroups within it. Event 530 has aduration “E-D”, event 540 has “F-I” and event 550 has “H-G”. Likewise,event 560 has a duration “L-K” while event 570 has a duration of “N-M”.In this regard, it should be noted that the computation of durations ofevents may be performed after event logging has been turned off. Thisallows the operating system/framework to have little, if any, additionalload which may skew the results of the logging by introducingnon-application timing delays (i.e. the time taken to compute durations,etc.). Likewise, statistics upon the durations such as averages, graphs,etc. may also be prepared after event logging has been turned off.

The events of FIG. 5 are shown as uniquely occurring and not repeating.However, any one or more of the events depicted may be repeated or mayrecur many times. For instance, many pages of database results' may begenerated which would imply some repetition of event 520 and itschildren. In this case, the aggregation of the present invention wouldtake the durations for each occurrence of event 520 and consider them asingle event (i.e. an aggregate). Assume that event 520 is repeated witha start time X and end time Y. Then, in the aggregate, event generatepage has a total time taken of “J−C+Y−X” and has been performed twice.Knowing the count and total duration, an average can be computed andpresented to the user. Since the log contains all of the raw data, auser may peer into the details of the two instances of event 520 to seeif anything is anomalous.

The events of FIG. 5 may be better understood when translated from itsabstract event description to a real-world scenario. Assume, forexample, that event initialize application 510 refers the start-up ofweb browser application. After the application has “initialized” (i.e.been allocated memory to occupy, had its instructions loaded therein,etc.), the next event is generate page 520. Event generate page 520 muststart with its own initialization. Thus, event initialize page 530 mayequate to allocating memory and screen area to the window, but as shownin FIG. 5, must also include content that can fill the page. After thepage is initialized (event 530), then the next sequentially occurringevent is event generate component 540. Event 540 could be analogized togenerating the drop down lists, toolbars, tables, menus etc. that oftenoccupy a web page (i.e. its user interface elements). A necessary andsufficient condition for the completion of generate component 540 isevent database fetch 550 which would correspond to filling the componentwith the desired data (e.g. list of categories for the toolbar).

Once the web page is generated (i.e. filled with data and user interfaceelements, but also, displayed to the user), then event generate page 520has reached its end. After the end of event 520, event get request 560commences. If the user is presented with input choices from thegenerated page, then get request 560 would correspond to the applicationgetting a request (such as a search query) from the user based on whatthe generated page (event 520) has made available. After the request hasbeen obtained (i.e. event 560 has ended) a reply to that request may begenerated (event 570). Event logging takes account of the hierarchy ofevents as shown in FIG. 5, but also allows contextual grouping andstatistics gathering. In this descriptive view of FIG. 5, assume thatthe events get request 560 and generate reply for request 570 wererepeated many times for different types of data items. For instance, ifone request dealt with the database look-up of a movie, while the othera music album, then these events could be separated by their context.Hence, rather than aggregating the two instances of event 570 into asingle event, they could separated by their context of music albumversus book. Aggregation could still occur but within context. Forinstance, if there were five replies for books and three replies formusic albums, then the five book-related reply events could beaggregated into one while the three music-related reply events could beaggregated into another. From a hierarchical grouping standpoint, alleight (three music and five book) reply events are identical. Butdifferentiating by context, they could be considered separately, as theinvention's event logging provides for.

In this way, it may be possible to measure the speed/efficiency at whichlook-ups of books are performed in contrast with the look-up of musicalbums. This may have utility, for instance, if the size of the tableand records associated with books versus music were vastly different,thus yielding different reply event timings. According to one embodimentof the invention, the non-contextual hierarchical count of all eight(book and music) events 570 could be maintained in addition to thecontextual count of five events and three events as being separate.

FIG. 6 is a computer system diagram that utilizes and implements one ormore embodiments of the invention.

Illustrated is a computer system 610, which may be any general orspecial purpose computing or data processing machine such as a PC(personal computer). Computer system 610 is coupled to a network 600which may connect to one or more networks, such as a Local Area Networkor the Internet, enabling computer system 610 to transact informationwith other computer systems or information devices.

One of ordinary skill in the art may program computer system 610 toallow event logging that is capable of hierarchical and contextual eventgrouping as well as aggregation in a user customizable manner. Asdescribed above, event logging may be provided for in the operatingsystem or framework that is common to applications executing withincomputer system 610.

Computer system 610 has a processor 612 and a memory 611, such as RAM,which is used to store/load instructions, addresses and result data asdesired. Typically, when event logging is turned on, the instructionspertaining to implementing the logging (such as event object creation)are loaded into memory 611, executed by processor 612 and then given amemory space within 611 to execute. The implementation of the eventlogging center and associated functionality may derive from a low levelsource code such as assembler, a machine language or a higher levellanguage or derivative thereof that has been embedded with the operatingsystem/framework of the computer system 610. The instructionscorresponding to the event logging center as well as the log of eventobjects and its associated information (e.g. start and end timeindices), may be stored to any combination of a disk 618, such as a harddrive, or to memory 611.

Computer system 610 has a system bus 613 which facilitates informationtransfer to/from the processor 612 and memory 611 and a bridge 614 whichcouples to an I/O bus 615. I/O bus 615 connects various I/O devices suchas a network interface card (NIC) 616, disk 618 and to the system memory611 and processor 612. The NIC 616 allows the event logging results tobe displayed to users connected to network 600. For instance, referringback to FIG. 3, the remote web browser 340 may access the event loggingcenter and display the results therefrom via network 600.

Once event logging is completed and statistics thereafter computed, theycan be displayed to a user through a web browser which may be displayedonto a display device (e.g. monitor) such as display 620. Through otherinput devices, such as a keyboard and/or mouse (not shown), the user caninput their grouping preferences to the event logging center through theweb browser running on the computer system 610 and displayed via display620. In the case of a remote web browser, the NIC 616 is used to receivethat remote user's grouping preferences and send event center resultsvia network 600.

1. A method of logging events for at least one application that operateson an operating system of a first computer, the method comprising:receiving a request from a particular application to log an event of theapplication; determining that event logging is turned on; in response tosaid request and said determination, creating an event objectcorresponding to the event in a first memory space that is separate froma second memory space in which said application operates; receiving,from the application temporal data regarding the event; storing thereceived temporal data in the event object; and processing the storedtemporal data in order to produce processed event data when it isdetermined that the event logging is turned off, wherein said receivingthe request, said creating, said receiving the data, said storing, andsaid processing are performed by an event logging mechanism that is partof said operating system and operating independently from saidapplication on the first computer on which said application operates.